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^ 1 SERIALIZERS 

SECTION I — ABSTRACT 

This paper presents an implementation mechanism, specification language, and proof techniques 
for prob ems involving the arbitration of concurrent requests to shared resources. This mechanism is 
the senalizer, which may be described as a kind of protection mechanism, in that it prevents improper 
orders of access to a protected resource. Serializers are a generalization and improvement of the 
monitor mechanism of Brinch-Hansen and Hoare. 

Serializers attempt to systematize and abstract desirable structural features of synchronization 
control structure into a coherent language construct. They represent an improvement in the modularity 
of synchronization over monitors in several respects. Monitors synchronize requests by providing a pair 

c-TAoT^'^t^r, ' 6aCh reqUest ty P c [exam P ,es are STARTREAD/ENDREAD and 
STARTWRITE/ENDWRITE for the readers-writers problemsl Such a pair of operations must be 
used in a certain order for the synchronization to work properly, yet nothing in the monitor construct 
enforces this use. Serializers incorporate this structural aspect of synchronization in a unified 
mechanism to guarantee proper check-in and check-out In scheduling access to a protected resource it 
is often necessary to wait in a queue for a certain condition before it continues execution. Monitors 
require that a process waiting in a queue will remain dormant forever, unless another process explicitly 
signals to the dormant process that it should continue. Serializers improve the modularity of 
synchronization by providing that the condition for resuming execution must be explicitly stated when a 
<-s process enters a queue, making it it unnecessary for processes to signal other processes. Each process 
determines for itself the conditions required for its further execution. 

The behavior of a serializer is defined axiomatlcally in terms of causal and incidental relations 
among events using the actor message-passing model of computation. Different versions of the 
readers-writers problems are used to illustrate how the structure of a serializer corresponds in a 
natural way to the structure of the specification of synchronization problems. 

In this paper we present specification and proof techniques using partial orders on computational 
events for dealing with problems involving fairness, starvation, and guaranteed concurrency Our 
techniques represent a significant advance over previously developed techniques using global states 
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SECTION II — PARALLELISM in PROBLEM BOLVINfl 

Serialize™ have been developed as a modular arbitration primitive for actor systems to aid 
investigating the issues of parallelism in problem solving. Conceptually an actor is an object that has 
both procedural and data aspects. The behavior of a primitive actor such as a serializer is defined by 
the ordering relationships among the events caused by the actor. 

We now feel that parallelism may have a more important role than previously realized in 
explicating the structure of higher level symbolic processing. Until recently it has been widely accepted 
that parallelism is not suited for the higher level symbolic processing of problem solving Most 
psychological evidence seems to point to individual humans as being almost entirely serial in their high 
level problem solving. .'...& 

Recently the development of actor message passing semantics has brought about a shift in our 
paradigm for problem solving. Early programs written to be expert in some domain were thought to be 
analogous to an individual human expert who was expert in the domain. Most programs were 
developed on the basis that there should be a single unified coherent intelligence directing all aspects of 
the problem solving in a serial fashion. The development of the actor model of computation has 
encouraged us to develop a paradigm based on a society of experts communicating bv passing 
messages. This switch in paradigm has provided us with a rich source of ideas for problem solving 
strategies We are attempting to develop a dialo gue styje of programming which places its emphasis on 
the modular distribution of knowledge and clean means of communication between pieces of knowledge 
Thinking and programming in this new paradigm has in turn caused us to re-evaluate the case for 
parallelism. We note that societies often make good use of parallelism for a variety of purposes. 

The additional programming burden imposed by parallelism is the task of arbitrating the 
activities of modules running in parallel. By analyzing the structure of problem solvers that attempt to 
use parallelism at the highest levels of problem solving, we hope to further explicate the structure of 
problem solving. The explication of a modular arbitration primitive in this paper should contribute 
toward that aim. 

We see a need for the development of language constructs that are at least partially chosen for 
their provability. A language feature providing synchronization should be designed to provide usable 
axioms about the possible orders of events in a program. The language feature should guarantee that 
conditions needed to prove properties of programs are explicit in the axioms for the language feature. 

Serializers have been designed to facilitate the proof that schedulers implemented using them 
satisfy their specifications. The specifications of a protected resource typically involve stating both 
integrity and scheduling constraints. An integrity specification typically takes the form of a consistency 
constraint. A typical example of an integrity specification might be that the position and velocity of an 
airplane must be recorded for the same instant of time. A scheduling specification typically takes the 
form of a constraint on the time order of certain events. A typical example of a scheduling 
specification is that if two requests to write in a data baseare received in a certain order then the first 
request received will be honored before the other. We would like to be able to demonstrate how 
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mplernenting protected resources using serializes makes it easier to prove that they satisfy their 
spec f .cat.ons. In particular, we would like to develop techniques for proWng that schedule I 
n^plernented using serializes guarantee a reply to each request received. Guarameenfg ha a epfy wi. 
be sent for every request received is a stronger and more useful property than merely beine free of 
sy^hJon^ WHiCh " tHC $ChedUHng 8peCinCaUon ™" «~' treated Tnl^llTature on 
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SECTION HI — SERIALIZERS 

III.1 — Concept of a Serializes 

In this section we will describe an abstract mechanism called a serializer for guaranteeing the 
integrity of a protected resource. The mechanism is an abstraction and encapsulation of the method 
commonly used in operating systems. A detailed analysis of the facilities needed will be used to 
motivate our design decisions. 

A serializer bears an analogy to the front desk of a hospital in that only one person can check in 
or out at a time. The front desk of a hospital serves to schedule the entrance and exit of people in the 
hospital. Entering or leaving the hospital is impossible without checking through the front desk. 
Various queues are maintained for people who are waiting. In addition records are maintained of 
where people are within the hospital. 

Serializers are modular in the sense that they can be constructed to encase the resource to be 
protected in such a way that it can only be accessed by passing through the serializer. A serializer 
should be constructe d to surround the protected resource in such a way that it is impossible to 
accidently avoid passing through it when using the protected resource. We shall avoid in this paper 
the issues involved with exactly how one guarantees that a serializer has sole possession of a resource, or 
even if cooperating serializers might share access to a resource. The reader may assume that every 
serializer we deal with in this paper has sole access to the encased protected resource. 

We can diagram how a serializer can be used to schedule access to a protected resource P as follows: 
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Diagram of Serializer Encasing a Protected Resource 
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. Each arrow in the above diagram is labeled with the kind of computational event it represents. 
J,* ™i S faU int0 two dis J° int cate gories that are totally ordered in time: those which 
GAIN-POSSESSION and those which RELEASE-POSSESSION of the serializer. Each event in the 
former category subsequently causes an event in the latter category to occur. Furthermore after a 
GAIN-POSSESSION event has occurred, then another such event will not occur until after the former 
has caused a RELEASE-POSSESSION event. A typical sequence of events occurring in the use of the 
protected resource P begins with a SERIALIZER-REQUEST event in which the serializer receives a 
message M which is intended for the protected resource P. The request must eventually result in an 
ENTRY event which gains possession of the serializer. A GUARANTEE request can be used in order 
to wait until some condition is true before proceeding. Such a request releases possession of the 
serializer. If a reply is received for the GUARANTEE request then it will be called an ESTABLISHED 
event because the condition is guaranteed to have been established at the time of the reply. Thus each 
ESTABLISHED event regains possession of the serializer at a point in time when the condition is 
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guaranteed to be true. The above sequence of GUARANTEE and ESTABLISHED events may occur a 
number of times in order to sequentially guarantee a number of conditions in succession. When the 
proper condition for using a protected resource has been established then possession of the serializer 
can be released by a JOIN-CROWD event which records that there is another process in the crowd 
using P. Next the message M is delivered to the protected resource P in a RESOURCE-REQUEST 
event. Eventually the protected resource P may produce a reply R to the request which will be called a 
RESOURCE-REPLY event. The RESOURCE-REPLY will eventually result in a LEAVE-CROWD 
event which regains possession of the serializer and records that the process is no longer in the crowd 
using P. The next event is an EXIT event, which releases possession and causes a 
SERIALIZER-REPLY event in which the message R is sent as the reply to the original 
SERIALIZER-REQUEST event. 

Serializers derive their name from the fact that all of the events that gain and release possession 
of the serializer are totally ordered (serial) in time. We assume that every serializer is written such that 
an event gaining possession is always followed by one releasing possession (usually this is trivial to 
demonstrate). In the above diagram the interior of the serializer has two "holes", in which a process 
may temporarily release possession of the serializer. The purpose of the hole entered by ENQUEUE is 
to wait for some condition to become true. The purpose of the hole entered by JOIN-CROWD is to 
allow parallelism in the use of protected resources by releasing the serializer to another process. There 
may be any number of holes of either variety. 

To understand the behavior of serializers, one must understand the ways that possession of a 
serializer is gained and released. There are three ways to gain possession of a serializer: 

An ENTRY event, which gains possession as a result of a SERIALIZER-REQJUEST 
event. 

An ESTABLISHED event, which regains possession as a result of a GUARANTEE 
request with a condition established to be true. 

A LEAVE-CROWD event, which regains possession as a result RESOURCE-REPLY 

event from a protected resource. 

There are three ways to release possession of a serializer: 

A GUARANTEE event, which occurs in order to guarantee that some condition is true 
before continuing execution. 

A JOIN-CROWD event, which records that a process is using the protected resource. 
An EXIT event, which causes a reply to the original SERIALIZER-REQUEST event. 
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For any given serializer and process after an ENTRY event and before the corresponding EXIT 
event, exactly one of the following two conditions will hold: 

The process is in sole possession of the serializer (executing in the shaded region of the 
diagram). 

The process has released possession in order to wait for some condition before 
proceeding or to join a crowd of processes executing in some protected resource. 
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SECTION IV — SERIALIZER CONSTRUCTS 

In this section we present the language constructs used in the serializer mechanism. They have 
been developed to facilitate the implementation of the abilities enumerated above. We should note that 
while a LISP-like syntax is used, we regard the choice of syntax as minor. 

IV.1 — Creation 

A serializer is constructed by an expression of the form 

{create ..serializer 

(queues: collection_ of _queues_forjhe_8erializer) 
(crowds: coHectionj f .crowdsJorJhejteriatizer) 
(entry: body_ of _serializer) ) 

The queues are used to provide first-in-first-out service to processes waiting for some condition 
in order to continue execution. The crowds are used to record which protected resources are in use; 

If an actor constructed by an expression of the form given above is sent a message M in a 
SERlALIZER-REQUEST event then M will eventually be sent to body_of _f rializtr in an ENTRY event 
which gains possession of the serializer. At most one process can be in possession of a serializer at one 
time The queues and crowds for the serializer relate to its internal working and are explained in 
greater detail below. 

IV.2 — Queues 

Queues are provided to allow a process to wait until some condition is met before proceeding 
further. Serializes provide an enqueue command which has the following syntax to meet this need: 

(enqueue the_wait_queue 

(guarantee: the_condition) 
(theti: the.continuation) ) 

A process executing the above command immediately releases possession of the serializer with a 
ENQUEUE the_wait_queue to GUARANTEE the.condition event. It does not regain possession and 
continue with execution of ttw_continuation with an ESTABLISHED th».condilion event until all of the 
following pre-requjsites hold: 

1: All the previous GUARANTEE requests in th«_wait_quw have received replies that 
the condition was ESTABLISHED; i.e. the process is at the front of the queue. 

2: the_condition is true. 
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3. A JOIN-CROWD, EXIT, or GUARANTEE event has just occurred releasing 
possession of the serializer. 

Note that all of these pre-requisites must be simultaneously satisfied before execution will continue with 
the_continuation. 

It may be the case that there is more than one process which satisfies the above pre-requisites 
because each is at the front of a different queue. In this case it is not obvious which process should 
gain possession next. We recommend that serializes be constructed so that they satisfy the following 
property: 

4: There is no other process such that the above three conditions hold. 

If all four conditions hold then for a process, the it is guaranteed to get possession of the 
serializer next before any further ENTRY or LEAVE-CROWD events occur. In other words, 
conceptually at least, the condition that must be guaranteed for further execution is evaluated for each 
process that is at the front of a queue every time possession of the serializer is released. If there is only 
one whose condition is true then it gets possession next. 

/-^ The condition in the guarantee: clause of the enqueue command is potentially any Boolean 

expression without side effects. The expression is evaluated whenever possession of the serializer is 
yielded. We have found one particular form of expression to be quite useful, which is a test for 
emptiness of queues or crowds. This is written as: 

{empty: queue ^ queueg ...) 

Each queue listed must be empty for the expression to be true. The evaluation of an expression of the 
above form has no side-effects. It simply calculates the Boolean value for the expression. 

We wish the.condttion to be guaranteed to be true when execution continues with the_continuaiion 
This depends on several constraints: 

1: The evaluation of the_condition is free of side-effects. 

2: The value of the.condition must be unaffected by any execution by any process which does 
not possess the serializer. 

Given these constraints, we can say that the_condition must be true when execution resumes with 
the.continuation of an enqueue command. 
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IV.3 - Relaying Messages 

Within a serializer it is necessary to be able to temporarily release possession of the serializer in 
order to relay the message to the protected resource and then later regain possession with the reply from 
the protected resource. A command of the following form accomplishes this by transmitting a_m«stag« 
to a_protected_resource: 

{relay_to a_protected_resource 
[message: a_message) 
Uhru: a.crowd ) 
(thcn_fo: continuationJor_reply) ) 

An entry is made in a.crowd to record the presence of a process in a_protected_resourco and then 
possession is yielded. After a_protected_r«sourc« has replied to a_mes<age and possession of the serializer 
has been regained by a LEAVE-CROWD event then the entry is removed from a.crowd and the reply 
received is sent to continuaiionjor j-eply. We have observed that in many applications the reply received 
from a-protected-resourco is immediately returned as the value of the serializer in an EXIT event. 
Therefore, we adopt the convention that if the thenjto: clause is omitted from a relay _to expression, 
then an EXIT will be performed with the message received from the protected resource. 

During the time between the JOIN-CROWD and the LEAVE-CROWD events, the entry is a 
member of a.crowd. Thus by inspecting the various crowds of a serializer it is possible to determine 
which resources currently have processes executing within them. Crowds provide a better abstraction 
than integer counts for keeping records of which processes are currently executing in protected 
resources. 
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SECTION V — BEHAVI ORAL PROPERTIES OF SERIALIZED 

«, , i ThC pr ° perties of seria ""rs are stated somewhat informally in this paper since we believe that 
seriahzers aid intuitive reasoning about parallelism. A more rigorous treatment is possible, but is 
beyond the scope of this paper. 

Behavioral properties of serializes can be stated in terms of events and relations between events. 
We shall use the notation 

Ej --> E 2 

to indicate that the event E, precedes the event Ejj. The precedes relationship is an acyclic partial order. 
The events of processes that do not interact are not ordered. 

,u > c lR th ? rCSt ° f the paper We wi " re * uire that the P rt) tected resource is well-behaved in the sense 
that for each request sent to the resource exactly one reply will be received. 

Another requirement we will make is that every process that comes into possession of a serializer 
will eventually release possession. The intent is to exclude behaviors where the serializer is locked up 
forever by a process which is performing an infinite computation while in possession. We believe that 
^ this condition will usually be trivial to satisfy in practice since the code in a serializer simply has to 
decide whether to wait for some condition or join some crowd of processes executing in a protected 
resource. This decision must be made as efficiently as possible in order to maximize the thruput of the 
serializes Otherwise the serializer can seriously degrade the efficiency of a system by becoming a 
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Property of Mutual Exclusion 



The most fundamental property of a serializer is that processes mutually exclude one another 
t rom possession so that at most one process has possession at any given instant. For any given serializer 

IOIN rnnVn ta ,^SLl time f ° r '" ° f the ENTRY ' GUARANTEE, ESTABLISHED, 
JOIN-CROWD, LEAVE-CROWD, and EXIT events of that serializer. A process gains possession of a 
serializer starting with an ENTRY, ESTABLISHED, or LEAVE-CROWD event, and retains possession 
until it releases possession with a GUARANTEE, JOIN-CROWD, or EXIT event. We will use 
subscripts to indicate distinct invocations of a serializer. The property of mutual exclusion of 
possession of the serializer can be stated in terms of events as follows: 

Either the i-th possession precedes the J-th possession 



SERIALIZERS 



12 



GAIN-POSSESSION, 



RELEASE-POSSESSION 



-> GAIN-POSSESSION 



J 



RELEASE-POSSESSIQN 



i 



or the j-th possession precedes the i-th. 



GAIN-POSSESSION. 



<-- 



GAIN-POSSESSION 

I 



J 



RELEASE-POSSESSION 



J 



RELEASE-POSSESSION, 

where a CAIN-POSSESSION, event is either an ENTRYi, ISTAlLISHEPj, or LEAVE-CROWD, 
event; and RELEASE-POSSESSION t is the next event after GAIN-POSSESSION, which is a 
GUARANTEE,. JOIN-CROWD,, or EXIT, event. 



V.2 — Gaining Possession 

We would like to guarantee that any process that sends a request or reply to a serializer must 
eventually gain possession of the serializer. This property is satisfied by any serializer that has no loops 
in which possession of the serializer is not released in the loop. It is not clear that it is ever useful to 
violate this restriction. All of the serializer examples in this paper trivially satisfy this restriction 
because they have no loops at all. 

If the above restriction is satisfied then any SERIALIZER-REQUEST or RESOURCE-REPLY 
event must eventually result in a GAIN-POSSESSION event More precisely, if there is a 
SERIALIZER-REQUEST in the history of a computation then it is followed by an ENTRY event. 
Furthermore if there is a RESOURCE-REPLY event in the history of a computation then it is followed 
by a LEAVE-CROWD event. 
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V.2.a -- Fir st Come First Served for Entry 

Since serialize™ are designed to implement scheduling of access to protected resources it must be 
possible for them to observe the order of arrival of requests to the serialize™ in order to carry out 
certain scheduling tasks. Thus we provide that requests for entry into the serializer will be served in 

fh^ni a »^« »2^22. at thC SeriaUzer - In termS ° f CVentS this can be ^malized by supposing 
that SERIALIZER-REQUESTj and SERIALIZER-REQUESTj are two events such that such that the 
first arrives before the second: 

SERIALIZER-REQUESTj -> SERIALIZER-REQTJESTj 

The next event after SERIALIZER-REQUESTj is ENTRY, and the next event after 
SERIALIZER-REQUESTj is ENTRYj. We require that these two events be related as follows: 

ENTRY, --> ENTRYj 

V.2.b — Firs t Come First Served for Re-Entrv 

Similarly it must be possible for a serializer to observe the order of arrival of replies to requests 
s-\ sent to protected resources. Thus if RESOURCE-REPLYj precedes RESOURCE-REPLYj so that 

RESOURCE-REPLYj --> RESOURCE-REPLYj 
then we require that 

LEAVE-CROWDj --> LEAVE-CROWDj 

V.3 — Properties of Guaranteed Conditions 

V.3.a — The Guaranteed Con dition is True if Execution Continues 
Let C be the condition guaranteed in an event of the form 

ENQUEUE q -GUARANTEE c 

which is caused by executing an expression of the form 

{enqueue q 

{guarantee: C) 
{then: ...» 



/T\ 



LTnSrn th ! pr ° CeSS continues ' then the next event of the process is of the form 
fci>TABLISHED c and C is true at the instant of this event. 
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V.3.b — Internal Queues are First In First Out 

Suppose that q is an internal queue of the serializer S and that there are two events such that 

ENQUEUE q -CUARANTEE cl --> ENQJUEUE q -GUARANTEE C2 

[i.e. such that the former precedes the latter in the total ordering of the serializer] and that 
ESTABLISHED C2 is the next event after ENQUEUE q -GUARANTEB C2 . Then there is an event 
ESTABLISHED C1 which is the next event after ENQUEuE q -GUARANTEE cl such that 

ESTABLISHED C1 --> ESTABLISHED C2 

which says that ENQUEUE q ~GUARANTEE cl was served before ENQlJEUE q -GUARANTEE C2 since 
both guarantee requests were placed in the same queue. 

V,3.c — Priority for Waiting Processes 

Each time possession of a serializer is released, waiting processes are given the opportunity to 
continue execution. This property of serializers simplifies proofs that a scheduler guarantees replies to 
requests received and increases the responsiveness of schedulers by allowing waiting processes to proceed 
as soon as possible. Roughly speaking, if there are any waiting processes "ready to go" when possession 
of a serializer is released then the next event to gain possession of the serializer must be an 
ESTABLISHED event which gives one of those processes possession. In terms of events, a process will 
be said to be "ready to go" at the instant of a RELEASE-POSSESSION event if it is waiting because of 
a previous ENQUEUEq-GUARANTEE c event, but the corresponding ESTABLISHED event has not 
yet occurred and the following properties hold: 

1: The condition C is true. 

2: The processes at the front of the queue. Therefore all previous events that waited 
for some condition on Q have already continued with their condition ESTABLISHED. 



The above properties give internal queues priority over external queues. 
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SECTION VI — REL ATIONSHIP T O SEMAPHORE 

VII — Mutual Exclusion 

One of the most common uses of semaphores is to implement mutual exclusion of execution in 
protected resources. It is relatively easy to implement mutual exclusion using a semaphore. The idea is 
for each process to perform a P operation on the semaphore before using the resource and then to 
«« k M °P erat,on wnen finished u *ng the resource. The program mutu.L.xelusio,U given below 
can be used to construct systems that insure that a resource does not receive any messages while still 
processmg a previous message. Thus processes are guaranteed to mutually exclude each other from 
overlapp.ng execution in the protected resource. This simple example is presented to illustrate more 
concretely the concept of encasing a resource in a serializer. 

(mutual exclusion 1 source) , {mutual exelution of . ^^ ., ^ 

Vet (mutex = {create J>mary semaphore)) instructing a neu, binary semaphore called muiex 

in i=> -a_message {tnen returning an actor such that whenever it receives a menage 

(P mutex) - „ * 

,, , , .. , ;performt a P operation on mutex 

{let (result = (resource <= ..message)) ;then Mndt the me „ age |0 the regouree 

(v . »'*bcA that after the result it received 

f~*\ resuimr *° V 0peratU>n *' P^^rmed on the semaphore 

tand the result is returned 

e ,. f Sema P hor « are a very primitive synchronization method which can be used to implement the 
fi acilities needed by modular schedulers. In some ways semaphores are analogous to the goto construct 
which can be used to implement the control structures needed for modular programming. Serialize™ 
abstract the control structure of schedulers such as the simple one presented above They can be used to 
™!T!,! T ,arUy , ° f im P ,ementatl °ns by making the structure of the implementation more closely 
match the structure of the task to be accomplished. In this way the synthesis of schedulers from 
IZJrZ f° nS ls .! aci,itated , because se " a,izer * Provide facilities for directly implementing common 

soecTfLnnn!^ ' °T?J? "^u^ Furthermore P roof * «■« implementations satisfy their 
specificat.ons is facihtated because the structure of the serializer guarantees many properties of the 

im^emenlatlon W ° U,d ° therWiSe haVe t0 be P ainfu,, y extracted f rom a g ,0 ^1 analysis of the 

Tn «L f " ndamental inte e rit y constraint for mutual exclusion of the use of a resource is that if two 
requests SERIALIZER-REQUEST, and SERIALIZER-REQUEST, are made to the serializer then 
either the i-use completely precedes the j-use 

R ESOURCE-REQJUESTj 

I 
V 

^ RESOURCE-REPLY, --> RESOURCE-REQjUESTj 



V 
RESOURCE-REPLY 



J 
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or the j-use completely precedes the i-use. 

RESOURCE-REQUESTj 

V 
RESOURCE-REQJUESTi <-- RESOURCE-REPLY j 

| ■ J 

V 

RESOURCE-REPLYj 

which says that one process must enter and leave the protected resource before the other enters. 

(mutuaLexclu$ion_2 ^resource) s ;to enforce mutual exclusion for a resource 

(create ^serializer ;const met a serializer 

(queues: q) ;with one queue q 

(crowds: c) ;ana * one croud c 

(entry: ;such that when entry is gained to the serializer 

(s> =a_messag© ;u>ith a message 

(enqueue q ;t hen wait on q 

(guarantee: (empty. c» ;for the condition that the crowd c is empty 

(then: ;t hcn 

(relay jlo resource • sent to the resource 

(message: ajnessage) ;the message received by the serializer 

(thru: c))))))) ; pas sing through the crowd c 

It is easy to see that mutuaL*xclusion_2 implements the integrity specification given above. The 
following invariant is true each time a process gains or releases possession: 

"((•Imc)$1) 

The only way to enter the resource through the serializer is to pass through the crowd c, Furthermore 
the crowd is guaranteed to be empty whenever a message is relayed to the resource 

Actually mutuaLoxclusionJ implements a stronger specification: namely that if 
SERIALIZER-REQUESTj --> SERIALIZER-REQjJESTj 

then 

RESOURCE-REQUESTj 

■ I 
V 

RESOURCE-REPLYj -> RESOURCES-RE<tU£STj 

The proof of this stronger specification is given below. If we suppose that 
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SERIALIZER-REQUEST, --> SERIALIZER-REQUESTj 

then 

SERIALIZER-REQUEST, --> SERIALIZER-REQUESTj 

v ! 

ENTER, I 

ENQUEUE, ~> ENTER; 

I 
V 

ENQUEUEj 
follows from mutual exclusion for serializers. Therefore 

ENQUEUE, 

I 
V 

DEQUEUE, -> ENQUEUEj 

V 
DEQUEUEj 

since queues of a serializer are first-in-first-out. Since serializers are mutually exclusive we know that 

DEQUEUE, 

I 
V 

JOIN-CROWD, -> DEQUEUEj 

Therefore 



JOIN-CROWD, 

I 
V 

LEAVE-CROWD, -> DEQUEUEj 

since the prerequisite for DEQUEUEj is that the crowd must be empty. Now we can read off the 
desired answer by transitivity: 
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JOIN-CROWDj 

I 

v 

RESOURCE-REQUEST, 

I 
V 

RESOURCEREPLYj 

I . -■■ 

V 

LEAVE-CROWDi --> DEQUEUE] 

'■ y 

JOIN-CROWD, 

I 
V 

RESOURCE-REQUESTj 

One extremely common specification is that an actor must reply to each request it receives (a 
guarantee of service that implies that the actor is starvation-free and thus free of deadlock). For 
serializers this is expressed in Jerms of events by simply requiring that for every 
SERIALIZER-REQUEST event there is a corresponding SERIALIZER.REPLY event in the history. 
Similarly the resource can be required to reply to requests by specifying that for every 
RESOURCE-REQUEST event there is a corresponding RESOURCE-REPLY event in the history. A 
serializer constructed using mutual_exclusion_2 is guaranteed to reply to requests provided that the 
resource it encases is guaranteed to reply to requests. 

The code for mutual_exclusion_l looks slightly shorter than the code for mutuaL«xclusion_2, but that 
is largely due to the extra words that indicate the structure of mutual_«cclusion_2. In mutual_«xclusion_l 
the semaphore bookkeeping is explicit for the message passing to and from the resource. In 
mutual_exclusion_2 the required bookkeeping is implicit in the structure of the language construct. 
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SECTION VII — REA P ERS-WRITE RS PROBT.TCMfi 

VIII - Readers-Writers Intj. ffr |ty BneoHWfJ,.., 

to th e A rp?". d r erS " Writer t SeriaHZer iS intCndcd t0 P rolect the **&* of » resource by scheduling access 
to the resource ,n such a way that it is impossible for two processes to overlap in the^ Te of rh" 

™ VeTourcTreouest a ? e r r ich a mcssage is «^?s ££. ™ * 

RESOURCF WRITP ? ^ ' f hkh thCrC are tW0 S P ecial «•« RESOURCE-READ and 

:~«w ?SurSsk e°vr e rcqucsts the protectcd resource wi " »«-- -i— -* 

The integrity specification for a readers-writers serializer is that "a write reauest exclude ,11 „*u„. 
either j ^kializer-REQPESTj are two requests received by the serializer then 

RESOURCE-WRITE } -> RESOURCE-REPLY, --> 

RESOURCE-REQjUESTj -> RESOURCE-REPLYj 



or 



RESOURCE-REQUEST; --> RESOURCE-REPLY, --> 
RESOURCE-WRli-Ej --> RESOURCE-REPLY, 

VII.2 - Readers -Write rs Scheduling Spe cification* 

sched^TllZ °[ thC r u eaders - writers P rob ^ derive from the desirability of imposing stronger 
schedulmg specf .cat.ons than simply that the serializer must reply to requests that it receives " NoErtS 

resource Th. ™,™ P Kttd reS0Urce '"* wri,,r ls '"« crm " d <* «»'«" m the proved 

primed Mow * r """ S "' """""" '° mi «^^H «« of the .mptanenttttoSs .o b, 

!*• «»*o of He writer croud i. „« rar era ,„ r lfc> „ „„, 

I*. r.«l.r. cr»„i «„i ,*. wril . r c „ w „, n ,„ p ^ m „, m) „ r „ ,j, Mm , (jm# 
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The fact that all qf the above invariants are preserved will be immediately evident from inspection of 
the code of all the implementations given below. No complicated chain of reasoning will be required. 
This is an example of how properties of a scheduler implemented using serializers can be seen with 
greater perspicuity than is possible from implementations using less structured arbitration primitives 
such as semaphores. 

VIL3 - Writer Excludes Others 

Let us introduce no new constraints beyond the primary one of insisting that a writer has sole 
access to the resource. One possible implementation that would satisfy those constraints is the 
one-at-a-tiroe serializer presented above. Another implementation follows that would allow readers to 
access the resource concurrently. 

In the implementation below we provide that a resource which is to be scheduled for reading and 
writing will receive messages of the form {read (wing: directions) ) and {write Unity directions) ). The 
directions included in these messages can be as complicated as desired up to and including an arbitrary 
procedure for carrying out the transaction on the protected resource without side effects. Note that this 
degree of generality in the directions can complicate verifying that the resource will reply to each request 
which it is sent. Nevertheless, in the discussion below we will assume that the resource will always reply 
to requests of the form (read (using: directions) ) and {write (using: directions) ). 

((wnter_exclude_others =thej>esource) s ;a serializer which enforces that writers excludes others 

;from the resource is implemented by constructing 

(create serializer ;a serializer which has 

(queues: readers_q writers^) ;two queues called readers_q and writer s„q 

(crowds: readers writer) ; iu >o crowds called readers and writer 

(entry* ;after entry 

(cases ;there are two cases for the message 

(s> (read (using: ^directions)) ;receive a request to read the resource using directions 

(enqueue readers_q ;enqueue on the readers queue to 

(guarantee: (empty: writer)) .guarantee that there is no writer in the resource 

(then: ;when dequeued. 

(relay _jo the_resource ;deliver the message to the resource 

(message: (read (using: directions))) 

(thru: readers))))) ;passing thru the readers crowd 

(=> {write (using: -directions)) ;receive a request to write in the resource using directions 

(enqueue writers_q ;enqueue on the writers.q to 

(guarantee: (empty: readers writer)) 

guarantee that there are neither readers nor a writer in the resource 

(then: ;when dequeued, 

(relay jlo the resource ;deliver the message to the resource 

(message: (write (using: directions))) 

(thru: writer))))))))) ;passing thru the writer crowd 

It is easy to see that the above implementation guarantees that writers will exclude others from 
the resource since if there is an element in the writer crowd then alt the queues of the serializer are 
blocked. 
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((size writer) i 1) 
(if (nonempty: writer) then (empty, readers)) 

However, the above implementation does not satisfy the requirement that the serializer must always 
reply to requests which it receives since nothing forces the readers crowd to eventually become empty. If 
the readers crowd does not empty then a writer could be stuck forever in writers_q (this problem has its 
roots in the violation of our recommendation that no two processes should be "ready to go" in a 
serializer at the same time). Therefore the above implementation must be refined or interpreted in 
some way in order to meet the specifications. 

VII.4 — First Come First Served 

The implementation given below satisfies the specification that the protected resource is served on 
a first come first served basis. In addition, starvation is not possible with the firsLcomeJirstjserved 
serializer and a certain amount of concurrency is guaranteed. Note that the additional specification 
results in an implementation that is simpler than the previous one. The added simplicity is due to the 
ability of serializers to have processes waiting in a single queue for different conditions. 

^ «first_come_first_served =the_resouree) s ;a first come first served serializer of the resource which 

;can be implemented by constructing 

(create_serializer ;a serializer which ha, 

(gucucs: waitings) ;a aueue called the WBitjng _ q 

(crowd*; readers writer) ;and two crowds called rmndm and *ri\Br 

y ' ;after entry 

(cases ^ \there are two cases for the message 

(=> (read (using: ^directions)) ;receive a request to read the resource using directions 

(enqueue waiting_q ;enqueue on the waiting queue to 

(guarantee: (empty, writer)) ; guarantee that there is no writer in the resource 

ithen: ;when dequeued, 

(relays the_resource ;deliver the message to the resource 

(message: (read (using: directions))) 

(thru: readers))))) ;passing thru the reader* crowd 

(=> (write (using: redirections)) ;receive a request to write in the resource using directions 

(enqueue waiting.q ;enqueue on the waiting queue to 

(guarantee: (empty readers writer)) 

guarantee that there are neither readers nor a writer in the resource 

"* cn: iwhen dequeued, 

(relay_to the_resource ;deliver the message to the resource 

(message: (write (using: directions))) 

(thru: writer))))))))) ;passing thru the writer crowd 
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VII.4.a — Requiring Concurrency in Implementations 

In the readers-writers problems there is a basic integrity constraint that the serializer must 
maintain, which is to ensure that a writer does not have access to the resource at the same time as any 
other requestor. However, a simple one-at-a-time approach can easily guarantee this property. The 
more complex versions of the problem attempt to provide readers with concurrent access to the resource 
without starving the writers. When we say that some amount of concurrency is guaranteed, we mean 
that the specifications for the serializer require that certain readers be given the opportunity to access 
the resource at the same time. 

Note that a serializer cannot guarantee that the requests to a protected resource are actually 
processed in parallel, since either the structure of the resource or some externally defined scheduling 
policy may prevent actual parallelism. We say that readers Rj and R. are concurrent readers if 

JOIN-CROWDj --> LEA VE-CROWDj 

and 
JOINCROWDj — > LEAVE-CROWDj 

The specifications for the first-come-first-serve serializer include a requirement for concurrency. 
We can informally express this requirement as saying that whenever one reader's entry into the 
serializer (an ENTRY event) immediately precedes another reader's entry, and the second reader enters 
the serializer before the first reader enters the resource (a JOIN-CROWD event), then these two readers 
must concurrently be in the resource. We can also give a more formal specification in terms of events: 

If Rj and Rj are readers such that 

ENTRYj --> ENTRYj --> JOIN-CROWDj 
and 

there is no requestor X k (a reader or writer) such that 
ENTRYj -> ENTRY k -> ENTRYj 

then Rj and R: must be concurrent readers, i.e. 

JOIN-CROWDj --> LEAVE-CROWDj 

and 
JOIN-CROWDj -> LEAVE-CROWDj 

Note that the above requirement would be the same if we required that the requestor X k be a writer, 
although the proof would be somewhat more difficult. 
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VII.4.b — Proof of Guaranteed Concurrency 

A proof that the first_com«_firstj6erved serializer shown above satisfies the given concurrency 
requirement proceeds by assuming the existence of two readers with the given relationship, then 
showing that they must be concurrent readers. Since we have 

ENTRY, --> ENTRYj --> JOIN-CROWD, 

we know, that the reader R, must be in the waiting_q when the reader R, gains possession of the 
serializer. Rj must be enqueued directly behind R,, since by our assumptions there are no intervening 
entries to put other requestors in the waiting.* Therefore when reader Rj does get into the resource 
through a JOIN-CROWD event (thereby releasing possession of the serializer), then the requestor at the 
head of the waiting_q must be Rj and the condition of (empty, writers) must be true. We trwn appeal to 
the priority which serializers give to processes waiting in interal queues of the serializer. 

JOIN-CROWDj --> LEAVE-CROWD, 

Since we know that JOIN-CROWDj --> JOIN-CROWDj, and JOIN-CROWD, --> LEAVE-CROWD, 
we conclude that JOIN-CROWD, --> LEAVE-CROWD, which completes the ploof that R, and R, are 
concurrent readers. J 

VII.5 — Readers Priority 

The following serializer forces readers into the resource concurrently. However, we need to guard 
against starvation. Our approach is to allow all waiting readers to enter the resource, then to designate 
the writer which has been waiting as the new privileged writer, and keep further readers from entering 
the resource until the privileged writer has relayed its message to the resource. After the privileged 
writer has been served, then all readers which have been waiting for that writer to finish are allowed to 
enter the resource, and a new privileged writer is chosen. A reader may not deliver a message to the 
resource while there is a privileged writer, or there is a writer in the resource. A writer may not enter 
the resource unless it is a privileged writer, and there are neither readers nor a writer in the resource 
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((read_concurrently sthej'esource) s ;a serializer which enforce* concurrency among reader* of 

;the resource i* implemented by constructing 

(create^serializer ;a serializer which ha* 

(queues; readers^ writers^) ;i wo queue* called readers_q and writers.q 

(crowds: readers writer) tlu>0 crowd* called readers and writer 

(#?mr * : ;after entry 

(cases ;there are two ca*e* for the me*sage 

(s> (read (using: ^directions)) receive a request to read the resource using directions 

(enqueue readers^ .enqueue on the reader* queue to 

(guarantee; (empty; writer)) ; guarantee that there are no writer* in the resource 

^ thcn: ;when dequeued. 

(relay_jo the_resource ideliver the message to the resource 

(message: (read (using: directions))) 

(thru: readers))))) ;passing thru the reader* crowd 

(s> (write (using: =directions)) ;receive a request to write in the resource using directions 

(enqueue writers^q ;enqueue on the writer* queue to 

(guarantee; (empty: readers_q writer)) 

guarantee that readers.q, and writer crowd are all empty 
(then: ;w hen dequeued f 

(enqueue readers_q .enqueue on readers.* to 

(guarantee: (empty: readers writer)) 

; guarantee that there are neither readers nor a writer in the resource 

(*" cw: ;when dequeued f 

(relay jto thojrosourco ;deliver the message to the resource 

(message: (writ e (using: directions))) 

(thru: writer))))))))))) ; passing thru the writer crowd 

The above implementation is a little more complicated than the previous one. However, it is not 
difficult to show that writers exclude others using the technique used for the previous implementation 
since the following invariants are maintained: 

((size writer) £ 1) 
(if (nonempty, writer) then (empty readers)) 

In order to show that neither readers or writers can possible starve, consider the following "traf f ic 
diagram" for the queues and crowds of the serializer: 
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Entering readers Entering writers 

i i 

I writers_q 
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+ + + + 

II 

I | (empty: readers a writer) 

I I 
. V V 

reader 6_q 

1 I 
(empty: readers) | | (empty: readers writer) 

I I 

+ + + + 



readers writer 

Traffic Diagram for Queues and Crowds of read_concurr«ntly 

The idea of the proof is to first show that the readera_q must eventually empty, then to show that any 
writer in the writers_q must eventually migrate to the readera.q. These two conditions ensure that every 
read or write request to the serializer is eventually satisfied. 

VII»5.a — Proof that the Readers Queue Must Empty 

If there is a privileged writer in the reader*.*, theh there is only one such writer, and it must be 
at the head of the queue. A writer can only enter the readtrs_q after it has been dequeued from the 
writers.q, and the guarantee of every writer exiting the wrlttri.q is that the read#r§_q is empty. Thus, 
not only is it true that there may be only one writer in the rtadera_q, the writer must also be at the head 
of the queue if it is there. 

Processes may only enter the readers crowd or the writer crowd by first exiting the readers.q. We 
have assumed that the_resource is correct in that every message sent to the resource will eventually 
produce a single reply. Therefore, if a writer is at the head of the readerajq, it is guaranteed that no 
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messages will be sent to thej'esourcr f rom the serializer untilboth the readers crowd and the writer 
crowd are empty. 

By a similar argument, if a reader is at the head of the re®ders_q, the writer crowd must 
eventually empty, which implies that a reader at the head of the readercjq'' must eventually exit the 
queue. Once a single reader is dequeued from the readers.q all readers in the readers^q in front of a 
writer must be dequeued. For any reader in the readersjei an event of the form 
ESTABLISHED readers q must be followed by an event of the form JOIN-CROWD reader For every 
such JOIN-CROWD event, the serializer is released, and if the readers.q has a reader at its head, that 
reader must be dequeued, since the reader_q is the only internal queue with its guaranteed condition true 
(the writer crowd remains empty). 

Thus, we have shown that all readers must exit the readersjq if they occur before a writer in that 
queue or if there is no writer in that queue. Further, if a writer is at the head of the readers_q then it 
also must exit the readers_q. Once a writer exits the readers^ there may be no additional writers added 
to that queue until it is empty. Therefore, the readersjj must empty. 

VILS.b — Proof That No Process in the writers^ Can Starve 

The idea behind this proof is simple. Any writer in the writersjq is waiting for both the writer 
crowd and the readers jq must empty. By our assumption about the resource there must be a 
RESOURCE-REPLY message for any writer, so the writer crowd must empty. We have just proved 
above that the readers^ must empty. Therefore the process at the head of the writers_q must 
eventually be dequeued, which is sufficient to show that no process in the writersjq can starve. 

VIL5.C — Requiring Concurrency for Reader's Priority 

The readers-priority serializer is intended to give more thruput to readers at the expense of 
writers, while still guaranteeing that each write request will receive a reply. Our informal requirement 
is whenever one reader's entry into the serializer follows another reader's entry (regardless of 
intervening serializer entries), and the second reader enters the serializer before the first reader enters 
the resource, then the two readers are concurrent within the resource In terms of events, this 
requirement can be expressed as: 

If Rj and R: are readers such that 

ENTRYj --> ENTRYj --> JOIN-CROWDj 

then Rj and Rj must be concurrent readers, i.e. 

JOIN-CROWDj -> LEAVE-CROWDj 

and 
JOIN-CROWDj — > LEAVE-CROWDj 
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Note that the above requirement is stronger than the concurrency requirement given for 
first_como_first_servod. 

All readers that have entered the serializer and not yet in the resource are in the readers.q, and 
the only writer that can be hi the readers.q must be at the head of the queue. We have previously 
shown that once one reader can leave the readers.* then all must leave the readers.q and enter the 
resource. We note that by the axiom of giving internal queues priority over external queues all readers 
in the readers.q must enter the resource before any reply from the resource will enter the serializer 
(through a LEAVE-CROWD event). This completes the proof. 
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SECTION VIII ~ ANALYSIS of SERIALIZERS 

Villi — Comparison with Monitors 

Serializes are generalizations of the "secretary" concept which was conceived by Dijkstra and 
later developed into "monitors" by Brinch-Hansen, and Hoare. The purpose of serializers is to schedule 
access to shared resources in order to protect their integrity. Roughly speaking, serializers are analogous 
to monitors in the same way that actors are analogous to SIMULA-67 classes. A serializer is an actor 
that will allow only one process to have possession at a time whereas a monitor is a SIMULA-67 class 
that will allow only one process to be executing inside it at a time. A general principle of efficient 
operation that is applicable to both serializers and monitors is to try to keep the serializer [monitor) 
unlocked as much of the time as possible to keep it from being a bottleneck in the operation of a larger 
system. 

We believe that serializers are easier to write and verify in a modular fashion than monitors. 
The correctness of a serializer is independent of the way in which it is used. It is more difficult to 
verify the correctness of a monitor since the ordering of monitor operations and access to the protected 
resource is dependent on the programs using the monitor. Serializers support modular programming 
better than monitors because serializers can be sensibly nested inside one another whereas usually it is 
unprofitable to nest one monitor inside another because the outer monitor will be tied up while the 
inner one is in use. A further advantage for serializers is that use of a protected resource appears 
identical to the use of the unprotected resource in a program that uses the resource. 

Using serializers the condition associated with an enqueue command is explicitly stated in the code 
of the implementation whereas the conditions used in the WAIT statement in a monitor are syntactic 
constructs which do not explicitly state what condition must be guaranteed in order to proceed. A 
process which needs to wait for some condition to be guaranteed before it proceeds explicitly states the 
condition in the serializer. In our experience this feature lessens the number of internal queues and 
tends to simplify program proofs. 

Another difference is the use of crowds rather than counters to keep track of processes that have 
been allowed to access the encapsulated resource. While there is an additional cost associated with such 
accounting, we believe that the benefits will make the use of crowds a decided advantage. It is possible 
to examine the crowds to determine which processes are currently accessing which resources. We expect 
that this will have significant impact on debugging programs that use parallel processes. Furthermore, 
if some process must be terminated externally, then the resources It is accessing can be reclaimed in a 
modular fashion. 

Axioms about monitors and implementation of monitors are both made more difficult by the 
necessity of having an "urgent queue". Proofs of programs using the SIGNAL statement are made 
more complicated by the necessity of considering the possible effects of processes emerging from the 
urgent queue. Hoare states in his paper on monitors that he considers it to be good practice to exit a 
monitor immediately after a SIGNAL statement. We consider it to be a practice worthy of enforcement. 
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All internal queues in a serializer are explicit, and explicit signals do not occur. Rather, the conditions 
for emerging from a queue are explicitly listed at the point of enqueuing. 
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SECTION IX — MORE GENER AL SERIALIZERS 

Serializers need to be generalized in several ways in order to be a general purpose 
synchronization mechanism. 

Thus far in this paper we have restricted our attention to serializers which use f irst-in first-out 
queues as the mechanism for scheduling the release of processes waiting for some condition. It is 
necessary to generalize this mechanism in order to conveniently solve certain scheduling problems. For 
example Hoare has used priority queues to solve the disk head scheduling problem. Below we present 
an implementation of a virtual disk which efficiently schedules disk accesses to a real physical disk. 
The operations on the virtual disk are exactly the same as the ones defined on the physical disk. The 
implementation given below uses an algorithm similar to one used by Hoare in an implementation using 
monitors. However, it will be possible to prove that our implementation using serializers always 
performs all disk operations which are requested. It is not possible to prove this property for the 
implementation using monitors because a process might request the disk and then never release it. 
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((virtuaLdisk -physicaLdisk) m {a virtual disk behaves like a physical disk with optimized head motion 

{let , 

'lot 

(currertjposMon initially 0) ;the current portion initialized to 

(currenLdirection initially up) ;the ettrreM iir eetion of motion it initially up 

then 

(create_serializer ;create a ,erializer teith 

iprwrity_<tueuer. up.queue down_queue) ;tu>o priority queue, 

(crowds: disk users) . 

(entry: .^r. • • 

t t . ;after gaming possession 

(s> (disk^equest (operation: sop) (track: strackjium)) 

f wc«iw disk request with specified operation and track number 
* ei ;define the procedures waiLup and waiLdown as follows 

((waiLup) s . %i%e proce i ure waj^up is defined as follows 

(enqueue upjqueue (priority. track_number) 

;enqueue in the up queue with priority given by the track number 

(guarantee: ;to guaraniec tha% 

(and (empty: disk_users) ;no one is using the physical disk 

(or (empty: down.queue) ;and that either the down queue is empty 

(currenLdirection = up)))) ;or an upsweep is in progress 

f\ {then: ^urrenLposition <- trackjuimber) ; then update the position 

(currenLdirection «- up) 

(rclay^o physicaLdisk ;r elay the request to the physical disk 

(message: (disk^request (operation: op) (track: track_num)) 
(thru: disk_users)))))) ipassing thru the disk users crowd 

((waiLdown) e -,*«, procedure waiLdown is defined as follows 

(enqueue down.queue ;enqueue in the down queue 

(priority (number_ofJracks - trackjiumber)) 
(guarantee: 

(and (empty: disk^users) (or (empty up_queue) (currenLdirection m down)))) 
(then: (currenLposition «~ tracKjwmber) 
(current-direction «- down) 
(relayjto physicaLdisk 

(message: (request (operation: op) (track: track_num))) 
(thru: disk.users))))) 
then 

(rules tracMumber ;if the track number is 

(s> (> current position) (waiLup)) 

; greater than the current position then wait in the up queue 

(s> current position ;else if the track number is the same as the current position 

(rules currenLdirection ;i hen if the current direction 

(h> up (waiLdown)) .j, up then wait in the down queue 

(s> down (waiLup)))) {e i $e ^u in the up queue 

/*-N ( 5 > « currenLposition) (waiLdown))))))))) 

;else if the track number is less than the current position then wait in the down queue 
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The proof that the above implementation always performs disk operations which are requested is 
accomplished by showing that the disk head sweeps the disk in both the upward and the downward 
direction servicing all requests for the tracks which it passes over. There are two cases to the proof: 

Case 1: One of the queues is empty. This means that any requests in the other queue are 
served in order of smallest priority number. All of the requests will be served because 
any new entries in the nonempty queue must have higher priority numbers than the 
lowest priority number already in the queue. The priority numbers are bounded above 
by the number of disk tracks. Since the internal queues of a serializer have absolute 
priority for next possession of the serializer over external requests, it follows that only 
finitely many new requests can enter a queue during each physical disk operation. 
Therefore if one of the queues remains empty then the other will eventually empty. 

Case 2: Both the up_queu« and the down.queue are nonempty. The queue to be served is 
determined by the eurronLdiroction. The argument used in Case 1 can be used to show 
that if current.dir««on is up then it will remain up until up„qu«u« has emptied and 
currenLdirection will then be changed to down. An analogous result to the previous 
statement holds with "up" replaced by "down". 
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SECTION X — FUTURE WORK 

The simple specification that "starvation is prohibited" is common to almost all synchronization 
specifications. Yet serializes at present make no such guarantee. They do make it easier to prove that 
an implementation using a serializer is free of the danger of starvation by facilitating the proof that 
the serializer always replies to requests which it receives. We feel that research should continue to 
search for mechanisms that provide effective guarantees of such properties, yet also provide sufficient 
generality to cope with a wide range of problems. 

Serializers have potential for use in robust systems in that more information is available for error 
recovery. The additional information is useful for implementing debugging features, deadlock 
detection, and gracefully backing processes out of protected resources. 
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SECTION XI — CONCLUSIONS 

In this paper we have introduced a modular arbitration primitive called a serializer which is a 
generalization and improvement of the monitor construct previously developed by Brinch-Hansen and 
Hoare. Serializes aid in the synthesis of modular synchronizers because their structure corresponds in 
a natural way to typical specifications for useful synchronizers. The structure imposed by using 
serializes provides important guarantees that aid in proving that the implementation meets its 
specifications. 

The specifications for a serializer include integrity specifications relating the order of access to 
the type of access, and scheduling specifications to ensure that differing types of access occur in the 
proper order. Part of this ordering specification included a specification requiring that certain 
requestors must be given the opportunity to use the resource concurrently. In the readers-writers 
serializer, we gave the integrity specifications that readers and writers were mutually exclusive in 
accessing the resource, and that at most one writer could access the resource at a time. Our different 
solutions to the readers-writers problem resulted from different scheduling specifications. 

We have attempted to explicitly introduce facilities into serializers that directly correspond to 
synchronization specifications. The constraint that the resource is not being accessed by either readers 
or writers when a writer enters is explicit in the code of our implementations, as is the requirement that 
no writers are accessing the resource when a reader enters. Serializers provide that the condition for a 
waiting process to proceed is explicitly stated. In this way integrity specifications can be directly 
expressed in the language. Scheduling specifications are more complicated. We have been able to use a 
specification language based on partial orders among events to good effect to express scheduling 
specifications. Furthermore, the structure of the serializers has enabled us to give simple intuitive 
proofs that various scheduling specifications are satisfied by implementations that use serializers. 
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